…#683

- init does NOT scaffold wiring for Prisma Next (it skips the
  encryption-client scaffold — schema is derived from contract.json);
  say so instead of 'scaffolds the wiring'. (Copilot)
- eqlAsc/eqlDesc are free functions taking the column expression
  (eqlAsc(u.salary)), not zero-arg methods; fix the ORDER BY table row
  to match the code example. (Copilot)
- install-skills.ts: the skillsFor regression guard is a test asserting
  SKILL_MAP has an entry for every value in a maintained ALL_INTEGRATIONS
  list, not one that reads the provider registry; correct the comment. (Copilot)

Claude-Session: https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w

Prisma Next installs the EQL bundle through its own migration ledger
(migrations/cipherstash/ applied by `prisma-next migration apply`), so the
standalone installer is the wrong tool — running it applies EQL out-of-band
from the framework's ledger. `stash init --prisma-next` already skips the
installer; this closes the manual-invocation hole.

- New pure `prismaNextInstallGuard(cwd, { force })` (mirrors
  validateInstallFlags): returns actionable guidance when a Prisma Next
  project is detected and --force isn't set, else null. Called early in
  installCommand, before any DB I/O — fails fast with a pointer to
  `prisma-next migration apply`.
- --force overrides (deliberate standalone install escape hatch).
- messages.eql.prismaNextDetected as the stable leader.
- Tests: 4 unit (config-file detection, dep detection, --force override,
  non-prisma-next passthrough) + 1 pty-less e2e proving the wiring (refuses,
  exit 1, no DB). Skill gotcha + changeset updated.

Addresses CJ/Dan's #683 review ask to enforce this in the CLI.

Claude-Session: https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w

…s; cipherstashFromStackV3 -> cipherstashFromStack

Aligns the EQL v3 authoring surface with the stack / Drizzle types.* catalog
(the cipherstash. namespace already disambiguates):

- v3 PSL column constructors drop the Encrypted prefix, at the single
  derivation seam (contract-authoring.ts v3PascalName): EncryptedTextSearch
  -> TextSearch, EncryptedDoubleOrd -> DoubleOrd, EncryptedBoolean -> Boolean,
  EncryptedJson -> Json, etc.
- v3 one-call setup: cipherstashFromStackV3 -> cipherstashFromStack (v3 is the
  default); the v2 setup fn becomes cipherstashFromStackV2.

Deliberately unchanged:
- runtime value envelopes (EncryptedString/Number/BigInt/Date/Boolean/Json) —
  a separate write-side surface; Dan asked to leave them as-is.
- the cipherstash.*V2 legacy column constructors.
- generated contract.json + codec ids (they key off codecIds, not constructor
  names — so no contract regeneration needed, which sidesteps the broken
   on this branch).
- the eql* query operators.
- camelCase TS-authoring exports (encryptedTextSearch, …) keep their prefix for
  now — a follow-up will align them (kept v3CamelName unchanged to avoid
  desyncing the static exports).

Namespace stays cipherstash (not eql): it is the extension's vendor identity
(CIPHERSTASH_SPACE_ID, woven through every cipherstash/eql-v3/* codec id and
cipherstash:* invariant) — switching it would re-identify the whole extension.

Updated: example schema.prisma + db.ts + e2e, both READMEs, the
stash-prisma-next skill, and the authoring/psl-interpretation tests. Verified:
package builds clean, bundling-isolation 12/12, authoring/psl/column-types/
from-stack suites green, code:check clean. (Pre-existing env failures — live
tests, properties, migration-v3 — are missing-devdep/DB issues, not this change.)

Stacked on #683. v2 name per Dan; namespace + scope calls documented above.

Claude-Session: https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w

…s; cipherstashFromStackV3 -> cipherstashFromStack

Aligns the EQL v3 authoring surface with the stack / Drizzle types.* catalog
(the cipherstash. namespace already disambiguates):

- v3 PSL column constructors drop the Encrypted prefix, at the single
  derivation seam (contract-authoring.ts v3PascalName): EncryptedTextSearch
  -> TextSearch, EncryptedDoubleOrd -> DoubleOrd, EncryptedBoolean -> Boolean,
  EncryptedJson -> Json, etc.
- v3 one-call setup: cipherstashFromStackV3 -> cipherstashFromStack (v3 is the
  default); the v2 setup fn becomes cipherstashFromStackV2.

Deliberately unchanged:
- runtime value envelopes (EncryptedString/Number/BigInt/Date/Boolean/Json) —
  a separate write-side surface; Dan asked to leave them as-is.
- the cipherstash.*V2 legacy column constructors.
- generated contract.json + codec ids (they key off codecIds, not constructor
  names — so no contract regeneration needed, which sidesteps the broken
   on this branch).
- the eql* query operators.
- camelCase TS-authoring exports (encryptedTextSearch, …) keep their prefix for
  now — a follow-up will align them (kept v3CamelName unchanged to avoid
  desyncing the static exports).

Namespace stays cipherstash (not eql): it is the extension's vendor identity
(CIPHERSTASH_SPACE_ID, woven through every cipherstash/eql-v3/* codec id and
cipherstash:* invariant) — switching it would re-identify the whole extension.

Updated: example schema.prisma + db.ts + e2e, both READMEs, the
stash-prisma-next skill, and the authoring/psl-interpretation tests. Verified:
package builds clean, bundling-isolation 12/12, authoring/psl/column-types/
from-stack suites green, code:check clean. (Pre-existing env failures — live
tests, properties, migration-v3 — are missing-devdep/DB issues, not this change.)

Stacked on #683. v2 name per Dan; namespace + scope calls documented above.

Claude-Session: https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w

…ipherstashFromStackV3 → cipherstashFromStack (#685)

* refactor(prisma-next)!: drop Encrypted prefix from v3 PSL constructors; cipherstashFromStackV3 -> cipherstashFromStack

Aligns the EQL v3 authoring surface with the stack / Drizzle types.* catalog
(the cipherstash. namespace already disambiguates):

- v3 PSL column constructors drop the Encrypted prefix, at the single
  derivation seam (contract-authoring.ts v3PascalName): EncryptedTextSearch
  -> TextSearch, EncryptedDoubleOrd -> DoubleOrd, EncryptedBoolean -> Boolean,
  EncryptedJson -> Json, etc.
- v3 one-call setup: cipherstashFromStackV3 -> cipherstashFromStack (v3 is the
  default); the v2 setup fn becomes cipherstashFromStackV2.

Deliberately unchanged:
- runtime value envelopes (EncryptedString/Number/BigInt/Date/Boolean/Json) —
  a separate write-side surface; Dan asked to leave them as-is.
- the cipherstash.*V2 legacy column constructors.
- generated contract.json + codec ids (they key off codecIds, not constructor
  names — so no contract regeneration needed, which sidesteps the broken
   on this branch).
- the eql* query operators.
- camelCase TS-authoring exports (encryptedTextSearch, …) keep their prefix for
  now — a follow-up will align them (kept v3CamelName unchanged to avoid
  desyncing the static exports).

Namespace stays cipherstash (not eql): it is the extension's vendor identity
(CIPHERSTASH_SPACE_ID, woven through every cipherstash/eql-v3/* codec id and
cipherstash:* invariant) — switching it would re-identify the whole extension.

Updated: example schema.prisma + db.ts + e2e, both READMEs, the
stash-prisma-next skill, and the authoring/psl-interpretation tests. Verified:
package builds clean, bundling-isolation 12/12, authoring/psl/column-types/
from-stack suites green, code:check clean. (Pre-existing env failures — live
tests, properties, migration-v3 — are missing-devdep/DB issues, not this change.)

Stacked on #683. v2 name per Dan; namespace + scope calls documented above.

Claude-Session: https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w

* fix(prisma-next): complete the camelCase rename — pascal/camel must agree

CI (Node 22/24 unit job) caught what my local env masked: test/v3/properties.test.ts
asserts the PSL (pascal) and TS-authoring (camel) constructor names agree modulo
first-letter case. My earlier deferral of the camelCase exports broke that
invariant (pascal 'TextSearch' vs camel 'encryptedTextSearch'), and the property
test only runs with fast-check installed (absent locally, present in CI).

- v3CamelName drops the prefix too (encrypted<Core> -> lowercase-first<Core>),
  restoring the pascal/camel invariant.
- The 31 static TS-authoring exports rename in lockstep: encryptedTextSearch ->
  textSearch, encryptedDoubleOrd -> doubleOrd, encryptedBoolean -> boolean, etc.
  (column-types.ts + its two test consumers). The v2 encryptedStringV2 descriptors
  and the runtime encrypted*ParamsSchema arktype schemas are deliberately untouched.
- properties.test.ts: the assertion updated to the new convention (name does NOT
  start with 'Encrypted', is PascalCase, camel = lowercase-first(pascal)).
- Changeset updated: camelCase exports move with the PSL names (no longer deferred).

Ran the FULL prisma-next suite locally after `pnpm install` (which restored the
missing devdeps my earlier local runs lacked): 599 passed / 30 skipped, including
properties + column-types. Build clean, code:check clean.

Claude-Session: https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w

* test(prisma-next): update negative factory assertions to new-convention names

Follow-up to the camelCase rename: the 'no *OrdOre / no string factory'
negative assertions checked old-convention names (encryptedBigIntOrdOre,
encryptedString) that never existed either way — pass, but off-convention.
Now check the new-convention names (bigIntOrdOre, textOrdOre, string).

Claude-Session: https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w

* docs(prisma-next): fix stale pre-rename names in messages, comments, README

Copilot review on #685 — the rename left several references pointing at the
old constructor names:

- from-stack-v3.ts / from-stack.ts: the "no columns found" errors told users to
  declare `cipherstash.Encrypted*()` — now `cipherstash.*()` (e.g.
  `cipherstash.TextSearch()`) for v3 and `cipherstash.Encrypted*V2()` for v2.
- contract-authoring.ts: the constructor-name doc said `Encrypted<Stem><Suffix>`;
  the prefix is dropped now (`eql_v3_bigint_ord` → `BigIntOrd`).
- bundling-isolation.test.ts: the marker-collision note had the substring
  direction backwards post-rename — `cipherstashFromStackV2` is NOT a substring
  of the v3 `cipherstashFromStack`; the hazard is now the reverse.
- README Quick start: the v3 schema example was wired to the v2 setup
  (`cipherstashFromStackV2` from `/stack`); use `cipherstashFromStack` from
  `/v3` so the snippet actually runs against a v3 contract.

No behavioural change. prisma-next build + 599 tests green.

Claude-Session: https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w

…shipped

Dan's review on #691: the `stash eql migration --prisma` copy said the flag
"ships with prisma-next EQL v3 support" / "not available yet" — but that support
has shipped (#655/#683/#685), and Prisma Next installs EQL v3 through its OWN
migration system (`prisma-next migration apply`), not through this command.

Reframed all five spots to current reality (not "coming soon", but "use
prisma-next migration apply"): the user-facing message + its doc comment, the
`eqlMigrationCommand` code comment, the `--prisma` flag help in the registry,
the changeset, and the stash-cli skill (which ships to customers).

No behaviour change — `--prisma` still fails with a pointer. Build + 566 tests green.

Claude-Session: https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w

…QL install) (#691)

* feat(cli): add `stash eql migration --drizzle` (v3, migration-first EQL install)

First of the three PRs in #690: make migration-first, ORM-agnostic EQL v3 install
the front door, so every integration sources install SQL from one place (the CLI's
bundled variants) instead of vendoring its own. This is the pattern that keeps
Drizzle Supabase-safe; prisma-next's superuser-on-Supabase failure is fixed by the
stacked follow-ups (`--prisma` emitter + removing prisma-next's baked baseline),
which land on top of the prisma-next EQL v3 work (#655).

`stash eql migration --drizzle [--supabase] [--name] [--out] [--dry-run]`:
- Generates a Drizzle custom migration (via `drizzle-kit generate --custom`, then
  injects the SQL) carrying the bundled EQL **v3** install script + the
  `cs_migrations` tracking schema — one `drizzle-kit migrate` does everything
  `stash encrypt …` needs.
- `--supabase` appends the v3 role grants (`eql_v3` + `eql_v3_internal` →
  anon/authenticated/service_role), matching `stash eql install --supabase`.
- v3 only — no `--eql-version` (prisma-next never shipped v2).
- `--prisma` is registered but fails with a pointer to #690 until the stacked PR.

The SQL assembly (`buildEqlV3MigrationSql`) is a pure, unit-tested function; the
drizzle-kit scaffold/inject orchestration reuses the proven helpers from the v2
`install --drizzle` path (`findGeneratedMigration`, `cleanupMigrationFile`, now
exported). Registry + dispatch + help + `stash-cli`/`stash-drizzle` skills updated.

Tests: 4 new unit (bundle present, grants gated on --supabase, tracking schema),
544 CLI unit green, manifest resolves the command, biome clean. Changeset: stash minor.

Claude-Session: https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w

* fix(cli): harden `stash eql migration` per review (#691)

Addresses the review on #691 — correctness, security, telemetry, and coverage:

- Run the PROJECT-LOCAL drizzle-kit (`pnpm exec` / `npx --no-install`), not the
  `pnpm dlx`/`yarn dlx` download-and-run form, so it resolves the project's own
  drizzle.config.ts + schema. New shared `execCommand`/`execArgv` in init/utils
  (setup-prompt's private copy folded in).
- Invoke via `spawnSync` with an argv array instead of `execSync` on a shell
  string — a `--name` with spaces or shell metacharacters is now one inert token
  (no word-splitting, no command injection). Plus a `[\w-]+` name guard.
- Pass `--out` through to `drizzle-kit generate` (always) so the flag actually
  steers where the migration is written, and our lookup can't miss it.
- Validation exits and every abort throw `CliExit(1)` instead of `process.exit`,
  so the telemetry `finally` runs and the branches are unit-testable.
- Guard `loadBundledEqlSql` (corrupt bundle → clean error, not a fatal trace),
  add the missing `p.intro`, and call `printNextSteps()` so the now-preferred
  install path isn't less helpful than `eql install`.
- HELP banner lists `eql migration`.

Tests: 14 migration unit (target selection incl. `--supabase`-alone, name guard,
dry-run, argv threading, non-zero drizzle-kit, write-failure cleanup, SQL order),
3 `findGeneratedMigration` unit (now public API), e2e smoke + `eql migration
--help`. 557 unit / 65 e2e green, code:check clean.

Claude-Session: https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w

* fix(cli): bun exec must not surprise-download; drop type-erased test cast

CodeRabbit review on #691:

- `execArgv`/`execCommand` bun case emitted `bun x`, which auto-installs a
  missing binary from npm — contradicting the "run a project-local binary,
  never surprise-download" contract these helpers exist to honour (the npm case
  already passes `--no-install`). Bun supports `--no-install`; pass it for both
  the argv and shell forms. Updated the setup-prompt assertion to match.
- migration.test.ts: replaced the type-erasing `undefined as unknown as
  writeFileSync` hoisted-mock placeholder with a throwing placeholder cast to the
  specific type — fails loud if the mock factory never runs, and drops the
  `as unknown` (test files are plugin-exempt, but this is cleaner).

CLI build + 566 unit tests green; biome clean.

Claude-Session: https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w

* docs(cli): correct stale `--prisma` copy now that prisma-next v3 has shipped

Dan's review on #691: the `stash eql migration --prisma` copy said the flag
"ships with prisma-next EQL v3 support" / "not available yet" — but that support
has shipped (#655/#683/#685), and Prisma Next installs EQL v3 through its OWN
migration system (`prisma-next migration apply`), not through this command.

Reframed all five spots to current reality (not "coming soon", but "use
prisma-next migration apply"): the user-facing message + its doc comment, the
`eqlMigrationCommand` code comment, the `--prisma` flag help in the registry,
the changeset, and the stash-cli skill (which ships to customers).

No behaviour change — `--prisma` still fails with a pointer. Build + 566 tests green.

Claude-Session: https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w

* docs(cli): correct `--prisma` copy to match #690 (planned emitter, not "use prisma-next")

My previous pass framed `--prisma` as "not supported — use `prisma-next
migration apply`", which contradicts #690: the `--prisma` emitter IS a planned
follow-up (PR3) that writes the install migration in the framework `Migration`
shape and lets prisma-next DROP its baked install baseline. Pointing users at
`prisma-next migration apply` is the very approach #690 replaces.

Reframe all five spots to "not available yet — the Prisma Next emitter is a
follow-up tracked in #690; use `--drizzle` today": the message + its doc comment,
the `eqlMigrationCommand` code comment, the `--prisma` flag help, the changeset,
and the stash-cli skill. (The `stash eql install` guard + stash-prisma-next skill
keep their `prisma-next migration apply` wording — that correctly describes the
current baked-baseline install, which is a different thing from this CLI emitter.)

No behaviour change. Build + 566 tests green.

Claude-Session: https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w